                                                                     
                                                                     
                                                                     
                                             
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>
-=SOEN 6441 - Documentation Phase3=- </title>
<meta name="generator" content="TextMate http://macromates.com/">
<meta name="author" content="Buthainah Aldosary">
<link rel="stylesheet" type="text/css" href="style.css">
<!-- Date: 2013-05-15 -->
</head>
<body>
<div align="center">
	<h1>
	SOEN 6441- 1 2013 Collaborative Email Client </h1>
	<br>
	<br>
	<table border="1">
	<tr>
		<th>
			 Name
		</th>
		<th>
			 ID
		</th>
	</tr>
	<tr>
		<td>
			 Buthainah Aldosary
		</td>
		<td>
			 6302459
		</td>
	</tr>
	<tr>
		<td>
			 Musab M Mirza
		</td>
		<td>
			 6367216
		</td>
	</tr>
	<tr>
		<td>
			 Sukhjinder K. Narula
		</td>
		<td>
			 5285348
		</td>
	</tr>
	</table>
	<p>
		<b>
		Due Date: June 18, 2013 </b>
	</p>
	<p>
		<b>
		Version 3.0 </b>
	</p>
</div>
<h2>Introduction </h2>
<p>
	 This design document outlines the functional requirements and component design of the Collaborative Email Client system using textual descriptions and supporting diagrams. The functional requirements are listed, optimistic locking and conflict resolution technique used, tests as well as some software quality measurements.
</p>

<h2>Functional Requirements </h2>

<p>The functional requirements for phase 3 of the project are:</p>

<ul>
	<li>
	Send an email through a network to at least 3 clients.	</li>
	
	<li>
	Filters should apply to received email. </li>
	
	<li>When a meeting is created involving another person, they should be able to accept or decline the appointment and edit over the network. </li>
	
	<li>
	Create meetings with other email attendees and send an email informing them: The user can create a meeting a specify the recipients in the To field. Upon creating the meeting, an email is sent to each recipient with a custom body in the following format: </li>

	<li>
	Allow two instances of the program to concurrently edit over the network using optimistic locking. </li>

</ul>

<h2>Optimistic Locking and Conflict Resolution</h2>
<p>
	Optimistic locking assumes that multiple transactions can proceed without affecting each other, and that therefor transactions can proceed without locking the data resources that they affect. Prior to committing, each transaction verifies that no other transaction has modified its data. If at any point a conflict occurs, that conflict is handled by the system or the user, in which the user has the option to roll back.

	In our project, we have defined what constitutes as “conflicts” by breaking down the different scenarios and handling them. The next section demonstrates the algorithm used:
<br>
<br>
<b>Background</b>
<ol>
	<li>Assume that server is at revision 10</li>
	<li>My local DB is not up to date with server – so assume it is as revision 5</li>
	<li>I took revision 5 from my database, and without updating it with server, changed and now trying to save it to server as revision 11.</li>
	
</ol>

<b>Notes</b>
<ul>
	<li>This algorithm will take all three sources and will try to merge so that it incorporates server revision and my changes.</li>
	<li>This algorithm also consider characters like “.”, “,” and newline “\n” while merging changes.</li>
	<li>Three possible cases are:</li>
	<ol>
		<li>Addition at the given index</li>
		<li>Deletion at the given index</li>
		<li>Replacement at the given index – it simply means deletion, followed by addition</li>
	</ol>
</ul>

<b>How it works:</b>
<br>
<br>
At any given index, this algorithm will check if the UI or Server performs any change to this index. The algorithm behaves as follows:   

<h3>Case when neither UI nor Server changed this index</h3>
No conflicts
<h3>Case when only UI changed the index and Server did not changed it.</h3>
Perform the changes – no conflicts
<h3>Case when UI did not changed, only Server changed at this index</h3>
Merge the changes from server into UI and highlight insertions and strike out deletion performed by server
<h3>Case when UI and Server, both perform changes at the same index</h3>

<h4>UI Added at this index</h4>

<h5>Server also added</h5>
<p>UI changes are added followed by server changes as highlighted</p>
<h5>Server deleted</h5>
<p>UI changes are added followed by server changes as strike out</p>
<h5>Server replaced</h5>
<p>UI changes are added, followed by server deletion strike out and addition highlighted</p>


<h4>UI Deleted at this index</h4>
<h5>Server added</h5>
<p>Delete the part deleted at UI, followed by highlighted insertions by server</p>
<h5>Server also deleted</h5>
<p>Delete – no conflict</p>

<h5>Server replaced (deletion followed by addition)</h5>

<h6>Server replacement range starting index is same as UI</h6>
<h7>Server deletion end range is same or less than UI</h7>
Delete the part deleted by UI, followed by conflict of what server wants to add
<h7>Server deletion end range is greater than UI</h7>
Delete the part deleted by UI, followed by conflict area of what server wants to remove additionally, followed by conflict area of what server wants to insert additionally.
<h6>Server replacement range starting index is NOT same as UI</h6>
<h7>Server deletion end range greater than UI</h7>
Delete the part deleted by UI, followed by conflict area of what server wants to remove additionally, followed by conflict area of what server wants to insert additionally.
<h7>Server deletion end range is same or less than UI</h7>
Delete the part deleted by UI, followed by conflict of what server wants to add



<h4>UI Replaced at this index</h4>
<h5>Server added</h5>
Perform the UI replacement, followed by highlighted server addition
<h5>Server deleted</h5>
<h6>Server deletion range starting index is same as UI</h6>

<h7>Server deletion end range is same or less than UI</h7>
Perform the UI replacement – no conflict
<h7>Server deletion end range is greater than UI</h7>
Perform the UI replacement, followed by conflict area of what server wants to remove additionally, 


<h6>Server deletion range starting index is NOT same as UI</h6>
<h7>Server deletion end range greater than UI</h7>
Perform the UI replacement, followed by conflict area of what server wants to remove additionally, 
<h7>Server deletion end range is same or less than UI</h7>
Perform the UI replacement
<h5>Server also replaced (deletion followed by addition)</h5>
<h6>Server replaced range is same or within the range of UI</h6>
Delete what UI wants to remove (replace), followed by add what UI wants to add as conflict, followed by add what server wants to add as conflict
<h6>Server replaced range is NOT same as UI</h6>
Delete what UI wants to remove (replace), followed by add what UI wants to add as conflict, followed by add what server wants to add as conflict, followed by additional deletions of server as strike out

<br>
<br>
<b>Ending Notes:</b>
<br>
At the end of the algorithm, if something is added by UI, it is inserted without conflict.
At the end of the algorithm, if something is added by Server, it is inserted as highlight.
</p>
<div align="center">
    <img src="img/chart.jpg"  width="800" height="400">

</div>

<h2>Filters Applicability</h2>
<p>
	In addition to the filters implemented in phase 2, weights have been assigned to each filter so that the filter that is most strict is always applied to an email. To calculate weights we have broken it down into:

	If a field is not empty then:
	<ul>
		<li>From field: always =1.</li>
		<li>To field: split using the “,” and each part’s weight is 1.</li>
		<li>Subject field: split using the “ ” and each part’s weight is 1.</li>
		<li>Body field: split using the “ ” and each part’s weight is 1.</li>
	</u>
	In the end, the filter’s weight is the sum of the weights of all the fields.
</p>
<div align="center">
    <img src="img/weight.png"  width="450" height="300">

</div>
<br>

<h2>Testing</h2>
<p>
As previously stated in phase 2, our system has been tested using the JUnit 4 Framework for the Java Programming Language. However, to increase test coverage for missed database functions in phase 1 and 2, Mockito has been used to mock and test these aspects. EclEmma Java code coverage plug-in for eclipse was used to measure the percentage of code coverage. The total code coverage for unit tests is in the client project is 34.9% and in the server project is 59.7%.
</p>
<h2>Software Quality Measurements</h2>




<script type="text/javascript" src="http://code.jquery.com/jquery-1.9.1.min.js">
</script>
<script type="text/javascript" src="js/custom.js">
</script>
</body>
</html>